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1.0 Introduction 

This paper describes PRC’s experience to date with a software engineering 
environment framework tool called the Automated Product Control 
Environment (APCE). The paper presents the goals of the framework 
design, an overview of the major functions and features of the framework, 
a summary of APCE use to date, and the results and lessons learned from 
the Impl ementati on and use of the framework. Concl usions are drawn from 
these results and the framework approach Is briefly compared to other 
soffware development environment approaches. 

2.0 Framework Goals 


The APCE was developed to reduce software l ifecycle costs. The approach 
taken was to Increase automation of the software I Ifecycle process and 
thereby to Increase productivity. It was felt that maximum cost 
reduction could be achieved for the short term by attack! ng three major 
problem areas: 

o automation of labor Intensive but routine administrative tasks 

o provision of an overall control, coordination, and enforcement 
framework and Information repository for existing tools 

o provision for maximum framework portability, distrlbutabl I ity, 
and data Interoperabil ity with the bounds of performance constraints 

A distinction was made between tools and the environment. In the PRC 
view, tools are active elements In the software l ifecycle process. They 
create or modify (document or software) components, test components, or 
order the execution of groups of tools upon components. The environment 
or framework, on the other hand. Is a more passive element. It provides 
for overall control, coordination, and enforcement and acts as an 
Information repository. This distinction Is Important because it serves 
to separate environment or framework Issues from tool Issues, PRC wanted 
to build a framework which could Incorporate existing tools. In this 
way, PRC could build on the excellent work done by others In the tool 
arena In a timely fashion. 
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3.0 APCE Overview 


The APCE provides automation for: 

o real-time project status tracking and reporting 

o conf Iguratl on management of software, documentation, and test 
procedures 

o requirements traceabll Ity and change Impact traceabll Ity 

o test bed generation, component Integration, and system 
I ntegratl on 

A brief overview of how the APCE Is organized to support these functions 
and how the APCE Is designed to support portabl I Ity, dl str Ibutabt I Ity, 
and Interoperability Is given below. 

3.1 Automation and Control 

As suggested by Stoneman a database provides the Integrating 
mechanism for the environment framework. The database design 
Incorporates a f lexlbl e model of the software development process. 

Project definition Information based on this model Is entered Into the 
database during project Initialization, and this Information Is used to 
control the project and provide the basis for automated tracking and 
configuration management. The project definition Is divided Into three 
components as Illustrated In Slide 3 (APCE Entitles), 

User groups are Identified as managers, developers (those who create 
products), or testers; multiple roles are allowed. The organizational 
hierarchy Is also described so that project problem reports can be 
automatically forwarded up the chain of command If they are not promptly 
dealt with. Products, both documents and software, are described 
In terms of their component structure and are associated with software 
I Ifecycle phases which are also entered Into the APCE database. SI Ide 4 
(APCE - DOD Documentation and Review Sequence) Illustrates the lifecycle 
phases as specified In Mfl-Std 2167. 

The levels of Integration describe the hierarchy of the test and 
Integration processes that all products (documents or software) must go 
through. This testing process allows for the enforcement of project 
standards and qual Ity assurance. The APCE uses the product structure and 
test procedures developed by the testers to automatically create testing 
base I Ines and test harnesses as requi red. 
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3.2 Portability, Dlstrlbutabl I Ity, and Interoperability 

The APCE approach to support for portability, dlstrlbutabl ! fty, and 
l nteroperabl I Ity Is based on three architectural features: 

o APCE Interface Set (A IS) 

o data-coupled design 

o open system architecture 

These features are Illustrated In Figure 1 (APCE Static View), which 
shows the APCE as part of a Software Engineering Environment (SEE), 

The APCE subsystems and data management capabil ities depend on a standard 
set of Interfaces to system services called the A IS. These Interfaces 
define a Stoneman Kernal Ada* Programming Support Environment (KAPSE) like 
layer for portabll Ity purposes. The A IS allows a mapping to existing 
operating system services. If the needed level of support Is not 
directly available from the host operating system, then an extra layer 
of software Is created to satisfy the requirement. Existing operating 
system services are not dupl Icated. The AIS Is not based on an Impl Iclt 
model like the Common APSE Interface Set (CAIS) C2H . 

The data-coupled design provides for both control and dl str l butabl I Ity . 

All project Information Is stored In the framework database. The 
database controls the activities of the APCE functional subsystems since 
they do not Interface directly but Interact through the database. Users 
do not directly manipulate the database; they affect the database 
contents Indirectly through Interaction with the functional subsystems. 

The database Is designed to minimize Information exchange, so data Is 
distributable (without replication). The functional subsystems are al so 
distributable since they are controlled by the database contents. The 
database design Is controled by the framework and hidden from the users. 
Thus, Integrity and Interoperability of data Is ensured. 

The open system architecture approach means that the APCE allows the use 
of existing host tools. Including management schedul Ing and costing 
tools. The APCE does not Interface directly with the tools but rather 
controls tool Invocation and the tool products. Both existing and future 
tools can be used within the APCE framework without alterations. 

4.0 Results 

The APCE has been used on a variety of In-house and cl lent projects over 
the past 21 months. It has been used In-house at PRC to support 
proposal and document production as wel I as software development and 
I Ifecycl e mal ntenance projects. The framework has also been Installed 
for Army, Navy, and Air Force cl lents. In one example cl ient 
Installation, APCE features were used to bring a software system under 
configuration control for a Navy software support activity. The 
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The full project team for Project 1 consisted of 9 persons. Including a 
manager, 2 computer system scientists, 1 system analyst, 1 analyst, and 4 
associate analyst /programmers. Two of the associate analyst/programmers 
acted as the test team. Al I of the other team members, except the 
manager, functioned as APCE developers. The senior staff members were 
quite experienced with 10 to 15 years experience each. The junior staff 
members were all new college graduates with no commercial programming 
experience and no VAX experience. The APCE allowed all personnel to be 
extremely productive despite their learning curve with a new machine and 
a new environment. 

4.2 Cost/Benefit Analysis 

PRC has conducted a cost/benef Its analysis of APCE use for one of our 
clients. This client needed configuration management and lifecycle 
maintenance control for mission critical software. PRC developed plans 
for both a manual and a APCE controlled development support facll Ity and 
plans for transitions to these facilities. A estimation of both 
the transition costs and the annual recurring resource costs was 
performed for both facll Itles. The results of the analysis are given on 
SI Ides 6 (Level of Effort Analysis) and 7 (Cumulative Cost Comparison). 

The estimated times for transition to both the manual and the APCE 
controlled facll Itles were the same (3 months). The activities Involved 
In the transition period Involve the establishment and Implementation of 
pol icles and procedures and. In the case of the APCE control led facll Ity, 
the Installation of software and training. As shown on Slide 6 (Level of 
Effort Analysis), the cost for transition In terms of effort was 
slightly more for the APCE controlled facility. However, the total labor 
months required for the first year and following years were very much 
less for the APCE controlled facll Itles. 

SI Ide 7 (Cumulative Cost Comparison) shows the total cumulative costs of 
the two facll Itles projected over a two year period. The larger Initial 
costs for the APCE controlled facll Ity Is caused by the APCE licensing 
fees. The cumulative costs of the manual facility surpass the costs of 
the APCE control I ed .facll Ity after seven months (4 months after 
transition). The cost savings achieved by the APCE facility are due to 
the Increased automation of the control, tracking, and configuration 
management functions. The estimates did not Include cost savings due to 
Increased productivity of developers and testers. 

4.3 Portabl I Ity 

The framework has proven very easy to rehost. Part of this ease Is due 
to the design features of the Al S and part Is due to rigid enforcement of 
coding standards for the transportable portions of the APCE. To rehost 
the APCE on a new machine, all that Is necessary Is to reimplement the 
AIS functions. The APCE transportable subsystems have been written In C 
using coding standards designed to eliminate use of "non- standard” 
features of the language. The C programming language was orglnally 
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framework Is now being used to continue control throughout the 
maintenance cycle. Including the Incorporation of module upgrades 
supplied by other contractors. These various applications of the 
framework have resulted In rehosting of the APCE to a variety of 
different hardware configurations. This experience In using the APCE has 
allowed PRC to collect the data on productivity, transportab! I Ity, and 
dl str l butabl I Ity presented below. 

4.1 Productivity 

At the National Security Industrial Association (NSIA) DOD/Industry 
Software Technology for Adaptable, Re! lab I e Systems (STARS) Program 
Conference In April 1984 C3, pg. L— 2 1 U , the NSIA Industry Study Task 
Group reported that the average productivity for U.S. software 
development projects was 200 lines of code per labor month. This works 
out to a little over 10 lines per day. On unclassified projects with 
APCE control, PRC has recorded productivity In excess of 120 lines per 
day. Slide 5 (Example Projects) gives the productivity figures collected 
for three PRC In-house projects under APCE control. (Client projects are 
not far enough along to report mean l ngful productivity figures.) 
Productivity In these three projects was an order of magnitude greater 
that the average reported for Industry as a whole. 

All of the reported projects used a high level programming language 
(HOL). Project 1 was the Initial development of a software system. This 
system has been maintained under APCE control. The figures given for 
Project 1 reflect only the developers' labor and do not count time for 
the manager or the testers (who basically functioned as Qual Ity Assurance 
personnel). Productivity during upgrades was equivalent or better than 
that experienced during the Initial development. Further details of 
Project 1 are given below. Project 2 was an upgrade to an existing 
system under APCE control. This upgrade Included full documentation. 
Project 3 was a prototyping activity, and Is somewhat atypical since only 
partial documentation (e.g. , no formal users manual ) was produced. The 
figures given for Project 2 and Project 3 Include the testers' time. 

These projects were small, so the same personnel functioned as both 
developers and testers. 

Project 1 was a four month project to develop system software In the C 
programming language. The development host was a VAX 11/780 and the non- 
APCE tools used are commercially available for the VAX. The project 
products Included: System Engineering Plan, Acceptance Test Plan, 
Functional Description, Preliminary Design Specification, Detailed 
Specification (22,000 lines of Ada PDL), Operators Manual, and Users 
Guide in addition to 58,297 lines of source code. In addition, 660 test 
procedures were developed and used to test the components of the 
products, (the test procedure development and test time Is not Included 
In the productivity figures given for Project 1.) Seme of these test 
procedures were used to enforce the project specific coding and PDL 
standards. 
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chosen because !+ was available on a wide range of host machines. 

However, 1+ has caused some problems because there are no standards for 
C. In the process of transporting, some features of C that were assumed 
to be commonly Implemented turned out to be system specif ic. A single 
version of the transportable soffware Is maintained that runs on all 
supported machines. (Future plans call for conversion to Ada as soon as 
there are Ada compilers on a sufficiently wide range of machines.) 

The APCE Is now running on the following machines: VAX 11/780 with VMS, 
ROLM and Data General with AOS/VS, IBM with MVS, and Intel 310 with 
XENIX*. Slide 8 (Rehost Efforts) presents a summary of rehosting 
experiences to date. 

4.4 DIstrlbutabll Ity and Interoperability 

The environment data Is Interoperable because the framework controls the 
database structure and because the franework controls only the products 
of tools rather Itian Interfacing directly with the tools. The toolsets 
available on different hosts may differ, but equivalent functional Ity Is 
usually available. Filters and standard forms can be used to adjust for 
differences befween specific tools. For example, different editors 
sometimes embbed control characters In the text. Filters are used at PRC 
head quarters to move text among the VAX EDT editor, the IBM PC Wordstar 
editor, and the Macintosh MacWrlte editor, A standard, plain text form 
has been establ Ished so that only one new filter needs to be written to 
Introduce another editor. 

Project data has been proven to be Interoperable between different 
framework Installations. Software and documentation have been routinely 
developed on one Installation and then transferred together with 
documentation, traceabil ity and conf lguratl on management Information, and 
project history Information to a different Installation on different 
hardware with no problems. This feature has proven useful In allowing 
project work to proceed In paral lel with the APCE rehost to new 
hardware. That Is, the early phases of a project can begin under APCE 
control on one machine while the APCE Is rehosted to the desired 
development host. When the rehost Is complete, the project can be 
transfered to Its own host. 

The framework was designed to function In a distributed, heterogeneous 
hardware environment. Both the database and the processing may be 
distributed. Work currently underway will allow distribution of 
developer processing to IBM PCs and Macintoshes connected to a VAX via a 
local area network. Future plans call for full distribution of both 
processing and data. 

5.0 Conclusions 

The preliminary results presented above provide good evidence that the 
APCE approach can achieve Its goals. The framework Increases 
productivity, allows use of existing tools w I th out modi f I cat I on, and Is 
easy to transport. PRC management has been Impressed enough to make the 
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APCE a company standard. The task of technology Insertion Into 
large projects has begun. Because of Its flexlblity, the APCE can be 
Introduced Into existing projects w l th out undue disruption. Most of the 
transition problems are In the areas of training. The use of the APCE 
does Involve understanding of some basic concepts. During the next few 
years, more data will be collected on the benefits of using this type of 
environment framework. 

The APCE framework approach Is In contrast with other environment 
approaches both In the areas of goals and of benefits. Many other 
recently developed environments, such as the Ada Language System (ALS) 
C43, have a very different set of goals. One of the goals of the ALS is 
to provide a minimal set of transportable tools Including a retargetable 
Ada compiler. Much of the effort expended In the ALS development has 
been to develop tools, especially the Ada compiler. Many of the benefits 
expected from the ALS are the benefits derived from the use of a standard 
tool set and command I anguage. 

The approach taken by the ALS does not allow the use of non-ALS tools. 

To work with the ALS, existing tools must be rehosted to the ALS KAPSE 
and rewritten in Ada, If necessary. The ALS tools are transported by 
rehost l ng the ALS KAPSE on new hardware just as the APCE framework Is 
transported by rehosting the AIS on a new operating system. The ALS 
approach means that there will be significant lead time before the ALS 
has a reasonably full tool set. Further, features such as full 
configuration management and project reporting must be added as tools to 
the ALS. These Important productivity tools are not part of the minimal 
toolset. Important aspects of the ALS approach, such as productivity and 
portabil fty, have yet to be proven. The problem of distribution was not 
directly addressed In the first version of the ALS. 

The ALS approach may work for organizations such as the U.S. Army that 
wish to standardize as much as possible on a minimal tool set and a 
limited selection of standard hardware. However, for a contractor with a 
wide variety of client and Internal standards, methodologies, and 
hardware, a much more flexible approach Is necessary. The APCE framework 
Is an example of a viable alternative approach. 
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Automated Product Control Environment 
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APCE Entities 
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Cumulative cost comparison 
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SOFTWARE ENGINEERING 
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DEVELOPMENT CHARACTERISTICS 
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COMPUTERS IBM MAINFRAME 

VAX-1 1/780 
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SOFTWARE TEST AND VERIFICATION PRACTICES 



